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1 Einleitung 


1.1 Vorbemerkung 


Die Jury Umweltzeichen hat in Zusammenarbeit mit dem Bundesministerium für Umwelt, 
Naturschutz und nukleare Sicherheit, dem Umweltbundesamt und unter Einbeziehung der 
Ergebnisse der von der RAL gGmbH einberufenen Expertenanhörungen diese Kriterien für die 
Vergabe des Umweltzeichens beschlossen. Mit der Vergabe des Umweltzeichens wurde die RAL 
gGmbH beauftragt. 

Für alle Produkte, soweit diese die nachstehenden Bedingungen erfüllen, kann nach 
Antragstellung bei der RAL gGmbH auf der Grundlage eines mit der RAL gGmbH 
abzuschließenden Zeichenbenutzungsvertrages die Erlaubnis zur Verwendung des 
Umweltzeichens erteilt werden. 

Das Produkt muss alle gesetzlichen Anforderungen des Landes erfüllen, in dem es in den 
Verkehr gebracht werden soll. Der Antragsteller muss erklären, dass das Produkt diese 
Bedingung erfüllt. 


1.2 Hintergrund 


Der jährliche Energieverbrauch der Telekommunikationsnetze und Rechenzentren in 
Deutschland lag im Jahr 2015 bei rund 18 TWh. Mit fortschreitender Digitalisierung wird dieser 
Wert im Jahr 2025 vermutlich auf 25 TWh steigen, insbesondere durch die Zunahme von 
internetbasierten Diensten!. Auch die Datenmenge, die über das Internet transportiert werden 
muss, nimmt kontinuierlich zu, zum Teil dramatisch. Laut der Bundesnetzagentur ist die 
Datenmenge im Festnetz zwischen 2011 und 2016 um das 4,5 fache gestiegen (28 Mrd. GB in 
2016). Im Mobilfunk ist der Anstieg der Datenmenge noch dramatischer, sie stieg gegenüber 
2011 um mehr als 800 % an (913 Mio. GB in 2016)?. Dennoch wird das Thema 
"Digitalisierung" nur selten in Verbindung mit Umweltbelastung gebracht?. Noch seltener wird 
erkannt, dass der Schlüssel zur Erhöhung der Energieeffizienz und Schonung natürlicher 
Ressourcen nicht nur in der Hardware, sondern insbesondere in der Software liegt. 


Die Rechenleistung hat sich seit 1970 etwa alle zwei Jahre verdoppelt. Das bedeutet, dass die 
Rechenleistung doppelt so schnell ausgeführt und somit für die gleiche Funktion weniger 
Energie verbraucht. Eine ähnliche Effizienzsteigerung ist bei Software nicht zu beobachten. Im 
Gegenteil, die Effizienzgewinne der Hardware werden durch höhere Softwareanforderungen 
und den Bedarf an größeren Datenmengen überkompensiert. Das führt häufig zum 
sogenannten Reboundeffekt, d.h. in Folge erhöhter Ressourceneffizienz steigt die Nachfrage 
nach einem Produkt oder einer Dienstleistung, sodass weniger Ressourcen eingespart bzw. 
teilweise zusätzliche Ressourcen benötigt werden als es bei konstant bleibender Nachfrage der 
Fall gewesen wäre*. Die Verfügbarkeit von immer leistungsfähiger Hardware führt dazu, dass 





1 https: //www.bmwi.de/Redaktion/DE/Downloads/E/entwicklung-des-ikt-bedingten-strombedarfs-in- 


deutschland-abschlussbericht. html 
? Bundesnetzagentur Tätigkeitsbericht 2016/2017 


https: //www.bundesnetzagentur. de/SharedDocs/ Downloads/DE/Allgemeines/Bundesnetzagentur/Publi 
kationen/Berichte/2017/TB_Telekommunikation20162017.pdf 











3 https://www.dbu.de/123artikel38000_2442.html 
4 Hilty, L. et al. (2013): Grüne Software - Ermittlung und Erschließung von Umweltschutzpotenzialen der 
Informations- und Kommunikationstechnik (Green IT) 
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Software von Version zu Version aufgebläht wird, sodass mehr Ressourcen in Anspruch 
genommen werden bei nur minimaler bis keiner Vergrößerung der Funktionalität. Beispiele für 
diesen "Software-Bloat" sind u.a. im Bereich der Betriebssysteme zu finden. Die Einführung 
eines Betriebssystems mit ggf. stark erhöhten Anforderungen an die Hardware führt nicht 
selten dazu, dass Hardware ausgetauscht werden muss, die grundsätzlich noch funktionsfähig 
ist. Aber auch im Bereich der Desktop-Anwendungssoftware lassen sich eindeutige 
Unterschiede in den Energie- und Ressourcenverbräuchen je nach genutztem Softwareprodukt 
feststellen bei Ausführung gleicher Aufgaben: so lag der Energiebedarf eines 
Textverarbeitungsprogramms viermal so hoch wie der Bedarf eines anderen 
Textverarbeitungsprogramms bei Abarbeitung des gleichen Standardnutzungsszenarios auf 
derselben Hardware (3,6 Wh im Vergleich zu 0,93 Wh)°. 

Software kommt demnach eine besondere Rolle zu, da die Eigenschaften und Funktionen der 
Software bestimmen, welche Hardwarekapazitäten benötigt werden und demnach, welche 
Energiebedarfe durch Informations- und Kommunikationstechnik (IKT) resultieren. 


Das Umweltzeichen Blauer Engel für Ressourcen- und energieeffiziente Softwareprodukte stellt 
insbesondere für Beschaffer*innen und Nutzer* innen von Softwareprodukten eine Orientierung 
dar und schafft Aufmerksamkeit für die Rolle der Software im Bereich IKT. Als erster Bereich 
der IKT wird sich auf Anwendungssoftware, die primär auf Desktop-Systemen läuft (vgl. 
Geltungsbereich), fokussiert. Eine Erweiterung des Geltungsbereiches auf weitere 
Architekturen, wie bspw. Client-Server-Systeme und mobile Apps, ist zu einem späteren 
Zeitpunkt angedacht. 


1.3 Ziele des Umweltzeichens 


Das Softwaredesign und die Programmierung der Software haben Einfluss auf die Ausstattung 
der Hardware ebenso wie auf die Höhe des Energieverbrauchs durch die Nutzung der Software. 
Mit dem Umweltzeichen Blauer Engel für "Ressourcen- und energieeffiziente Softwareprodukte" 
(DE-UZ 215) können Produkte gekennzeichnet werden, die im besonderen Maße sparsam mit 
den Hardwareressourcen umgehen und in ihrer Nutzung einen sparsamen Energieverbrauch 
aufweisen. Aufgrund geringerer Leistungsanforderungen wird eine längere Hardware- 
Nutzungsdauer möglich. Darüber hinaus zeichnen sie sich durch eine hohe Transparenz aus 
und ermöglichen Nutzenden besondere Freiheiten im Umgang mit der Software. Der Blaue 
Engel zeichnet die besten aktuell am Markt verfügbaren Produkte in einer Kategorie aus und 
nimmt dabei keine vergleichende Wertung zwischen Produkten vor. 


Ziel des Umweltzeichens ist es, den Energieverbrauch der Informations- und 
Kommunikationstechnik insgesamt zu reduzieren und die Ressourceneffizienz zu steigern. 
Produkte, deren Hersteller Informationen zu ihren Produkten, insbesondere zur Energie- und 
Ressourceneffizienz, bereitstellen, werden mit dem Blauen Engel für diese Transparenz 
besonders hervorgehoben. 

Zudem wird ein Produkt gekennzeichnet, dessen Hersteller sich aktiv für eine Verbesserung 
der Ressourcen- und Energieeffizienz seiner Produkte einsetzt. 





> https: //www. umweltbundesamt.de/sites/default/files/medien/1410/publikationen/2018-12- 
12 texte _105-2018_ressourceneffiziente-software_O.pdf 
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Daher werden im Erklärfeld folgende Vorteile genannt: 


www.blauer-engel.de/uz215 
e energieeffizient 


« ressourcenschonend 
« transparente Schnittstellen 





1.4 Begriffsbestimmungen 


Anwendungssoftware: Sind Softwareprogramme, die einen endbenutzerbezogenen 'Nutzen' 
erbringen. Beispiele für Anwendungssoftware sind: Bildbearbeitung, E-Mail-Programme, 
Webbrowser, Multimediaanwendungen, Textverarbeitung oder Tabellenkalkulation. 


Bereitstellungsende: Zeitpunkt, zu dem das Softwareprodukt nicht mehr länger durch den 
Antragssteller zur Verfügung gestellt wird, es kann weiterhin ein Support für das Produkt 
angeboten werden. 


Desktop-Computer: Bezeichnet einen Computer, dessen Haupteinheit an einem festen 
Standort aufgestellt wird, der nicht zur mobilen Nutzung ausgelegt ist und mit einem externen 
Anzeigegerät sowie externen Peripheriegeräten wie Tastatur und Maus genutzt wird. 


Escrow: Eine Hinterlegung der Quelltexte und Dokumentation eines Softwareproduktes bei 
einem unabhängigen Unternehmen oder Notar, sodass im Fall bestimmter Ereignisse (bspw. 
Insolvenz) Einblick in den Quelltext gewährt werden kann. Es wird hinterlegt, wann der 
Quelltext an den Anwender herausgegeben werden kann. 


Energieeffizienz: Allgemein die Menge an "nützlicher Arbeit" dividiert durch den dabei 
anfallenden Energieaufwand. Im Zusammenhang mit Softwareprodukten wird hier "nützliche 


Arbeit" als erfolgreiche Ausführung von Standardnutzungsszenarien verstanden. 


Hardware: Gesamtheit der für die Ausführung von Programmen, die Speicherung von Daten 
oder den Transport von Daten benötigten Sachgüter. 


Hardwarekapazität: Quantifizierbare Eigenschaft eines Hardwaresystems, die die Grenze 
seiner Leistungsfähigkeit auf einer gegebenen Leistungsdimension darstellt (z.B. 
Arbeitsspeicherkapazität, Rechenkapazität, Bandbreite). 


Hardwaresystem: Abgrenzbare Einheit von Hardware, die definierte Funktionen erbringt. 


Indikator: Eine empirisch bestimmbare Größe, die Aufschluss über einen nicht direkt 
messbaren Sachverhalt gibt. 


Leerlaufzustand: Zustand, in dem das Softwareprodukt gestartet wurde, aber keine 
Funktionalität ausführt. 


7/38 DE-UZ 215 Ausgabe Januar 2020 


Nutzungsmuster: Abstrahierte Form einer Sequenz von Interaktionen mit einem gegebenen 
Softwareprodukt. 


Nutzungsszenario: Beschreibung eines Nutzungsmusters, in der Regel maschinell 
ausführbar. 


Referenzsystem: Ein Hardwaresystem, das hinsichtlich seiner wichtigsten Kapazitäten (z. B. 
Arbeitsspeicher, Prozessorleistung) während einer festgelegten Zeitperiode (z. B. ein Jahr) als 
allgemein üblich definiert wird. 


Ressource: Eine natürliche Ressource bezeichnet insbesondere einen Rohstoff, eine 
Energieform oder auch die Absorptionsfähigkeit eines Umweltmediums für Emissionen. Zur 
Abgrenzung gegen technische Ressourcen, insbesondere Hardwareressourcen, werden letztere 
hier präziser als "Hardwarekapazitäten" bezeichnet. Da die Beanspruchung von 
Hardwarekapazitäten stets zur Beanspruchung natürlicher Ressourcen führt, ist diese 
Abgrenzung (die in letzter Konsequenz auf eine definitorisch schwierige Grenzziehung zwischen 
Ökosphäre und Technosphäre hinausläuft) hier nicht von entscheidender Bedeutung. 


Ressourceneffizienz: Allgemein die Menge an "nützlicher Arbeit" dividiert durch die dafür 
erforderlichen Ressourcen. Im Zusammenhang mit Softwareprodukten wird hier "nützliche 
Arbeit" als erfolgreiche Ausführung von Standardnutzungsszenarien verstanden. 


Software: Programme und zugehörige Daten in digitaler Form. 


Softwareprodukt: Eine lizensierbare Einheit von Software, und die zur Ausführung 
notwendigen Dienste, die zur Ausführung und Verarbeitung auf einem Hardwaresystem 
bestimmt sind. 


Softwarestack: Softwarekomponenten, die aufeinander aufbauen und gemeinsam das 
Softwareprodukt bilden bzw. zu seiner Ausführung notwendig sind. 


Standardnutzungsszenario: Ein Nutzungsszenario, das zum Testen eines Softwareprodukts 
verwendet wird und möglichst repräsentativ für den üblichen Anwendungsfall ist. 


Supportende: Zeitpunkt, zu dem weder das Softwareprodukt selbst durch den Antragssteller 
zur Verfügung gestellt wird (Bereitstellungsende) noch ein Support für das Produkt angeboten 
wird. 


System Under Test (SUT): Ein Hardwaresystem, dessen verbrauchte Energie und 
verwendete Hardwarekapazitäten gemessen werden (z.B. während des Ablaufs eines 
Standardnutzungsszenarios). Beinhaltet neben der Hardware auch sämtliche zum Betrieb des 
Softwareprodukts notwendige Software (Softwarestack: z.B. Betriebssystem, 
Laufzeitumgebungen, etc.) und die Konfiguration von Softwareprodukt und Softwarestack. 


Tabellenkalkulationsdatei zur Kriterienerfassung: Bei dieser Datei handelt es sich um 
eine Tabellenkalkulationsdatei, in der Daten zum Softwareprodukt, Referenzsystem, auf dem 
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die Messungen durchgeführt wurden, Standardnutzungsszenario sowie Ergebnisse der 
Kriterienbewertung des Softwareproduktes erfasst werden. 


Update: Eine aktualisierte, und ggf. verbesserte, Version eines Softwareproduktes. Aus Sicht 
der vorliegenden Vergabekriterien ist die Frage, ob ein Update vorliegt dann relevant, wenn 
nach einer Weiterentwicklung des zu kennzeichnenden Softwareproduktes ein neues 
Standardnutzungsszenario notwendig ist, d.h. wenn mit dem vorliegenden 
Standardnutzungsszenario die Hauptfunktionalitäten (typische Nutzerinteraktionen) nicht mehr 
vollständig abgedeckt werden. 


1.5 Ausblick auf mögliche zukünftige Anforderungen 


Aufgrund fehlender Messmethoden und Benchmarks sind in den vorliegenden Vergabekriterien 
des Umweltzeichens keine quantitativen Mindestanforderungen formuliert. Bei der nächsten 
Überarbeitung soll dieser Punkt geprüft und gegebenenfalls Mindestanforderungen gestellt 
werden. 

Im Geltungsbereich der vorliegenden Vergabekriterien sind die Softwareprodukte, die zur 
Gruppe der Anwendungssoftware mit Benutzerschnittstelle zugeordnet werden können. Bei der 
nächsten Überarbeitung der Vergabekriterien soll der Geltungsbereich insbesondere um die 
Server-Client-Softwareprodukte erweitert werden. Dafür ist u.a. die Festlegung eines 
Referenzsystems für Server notwendig. Mittelfristig wird auch geprüft, ob Systemsoftware in 
den Geltungsbereich einbezogen werden kann. 

Zudem wird bei der nächsten Überarbeitung geprüft, ob Prüflabore eingesetzt werden können, 
die die Messung des Energieverbrauchs und der Hardwareinanspruchnahme durchführen. 
Aufgrund fehlender Nutzungsstatistiken können die Standardnutzungsszenarien, mit denen die 
Ressourcen- und Energieeffizienz der Softwareprodukte zu bewerten ist, in diesen 
Vergabekriterien frei gewählt werden. Bei der nächsten Überarbeitung soll dieser Punkt geprüft 
und gegebenenfalls standardisierte Nutzungsszenarien pro Produktgruppe vorgegeben werden. 


1.6 Hinweise zur Antragsstellung und Nachweisführung 


Die in diesen Vergabekriterien formulierten Anforderungen an energie- und 
ressourceneffiziente Softwareprodukte gelten sowohl zum Zeitpunkt der Antragsstellung als 
auch während der Zeichenbenutzung. Die Einhaltung der Anforderungen muss vor der 
Zeichenvergabe mit der Antragstellung (Abschnitt 3.1) und, im Fall von Updates, während der 
Vertragslaufzeit (Abschnitt 3.2) sowie zum Ende der Vertragslaufzeit durch den Bericht zur 
Abschlussevaluation (Abschnitt 3.3) nachgewiesen werden. 

Zur Antragsstellung müssen alle in Abschnitt 3.1 genannten Nachweise vorgelegt werden. Der 
zentrale Nachweis bei der Antragsstellung ist die Tabellenkalkulationsdatei zur 
Kriterienerfassung, in der Daten zum Softwareprodukt, zum Referenzsystem, auf dem die 
Messungen durchgeführt wurden, das Standardnutzungsszenario sowie die Ergebnisse der 
Messkriterien des Softwareproduktes erfasst werden (Anlage 2). 

Die darin angegebenen Werte müssen durch Auditor*innen geprüft und bestätigt werden. Die 
RAL gGmbH benennt mit Unterstützung des Umweltbundesamtes dazu Auditor*innen. Durch 
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die Zulassung von Auditor*innen wird sichergestellt, dass die Prüfung der Werte unabhängig 
und mit hoher fachlicher Qualifikation erfolgt. 


2 Geltungsbereich 


Im Rahmen dieser Vergabekriterien wird ein Softwareprodukt folgendermaßen definiert: 

Ein Softwareprodukt erbringt einen endnutzerbezogenen Nutzen. Die vorliegenden 
Vergabekriterien des Umweltzeichens für energie- und ressourceneffiziente Softwareprodukt 
beziehen sich auf Anwendungssoftware, die über eine Benutzerschnittstelle verfügt und die auf 
einem der in Anhang D genannten Referenzsysteme lauffähig ist. Nicht unter den 
Geltungsbereich dieser Vergabegrundlage fallen Softwareprodukte, bei denen der 
überwiegende Anteil der Rechenarbeit nicht auf dem lokalen Computer erbracht, sondern auf 
einen entfernten Server ausgelagert wird. 


Zudem muss die Anwendungssoftware, auf die die Vergabekriterien anwendbar sind, die 
Anforderungen des Jugendmedienschutz-Staatsvertrages (JMStV)® in der jeweils aktuellen 
Fassung erfüllen und darf keine der im JMStV § 4 Unzulässige Angebote genannten 
Eigenschaften aufweisen. 


3 Anforderungen 


3.1 Anforderungen zum Zeitpunkt der Antragsstellung 


Die in Abschnitt 3.1 genannten Anforderungen sind zusammen mit der Antragstellung 
nachzuweisen. Der Nachweis bezieht sich auf die aktuelle oder eine explizit genannte Version 
eines Softwareproduktes. Auf dieser Grundlage wird der Zeichennutzungsvertrag zur 
Verwendung des Umweltzeichens vergeben. Bei Update dieser Version während der 
Vertragslaufzeit müssen darüber hinaus die Anforderungen in Abschnitt 3.2 erfüllt werden. 


Die Anforderungen unterteilen sich in drei Bereiche: 
e 3.1.1 Ressourcen- und Energieeffizienz 

e 3.1.2 Potenzielle Hardware-Nutzungsdauer 

e 3.1.3 Nutzungsautonomie 


3.1.1 Ressourcen- und Energieeffizienz 


Ein Softwareprodukt muss seine Funktionalität mit einem minimalen Ressourcenaufwand und 
Energiebedarf erbringen. Die Ressourcen- und Energieeffizienz des Softwareprodukts soll 
maximiert werden. Zur Operationalisierung der Ressourceneffizienz werden als Bezugsgrößen 
Hardwareressourcen und Energieverbräuche verwendet. 





6° Staatsvertrag über den Schutz der Menschenwürde und den Jugendschutz in Rundfunk und 


Telemedien (Jugendmedienschutz-Staatsvertrag - JMStV) in der Fassung des Neunzehnten 
Staatsvertrages zur Änderung rundfunkrechtlicher Staatsverträge (Neunzehnter 
Rundfunkänderungsstaatsvertrag), https: //www.kjm- 





online. de/fileadmin/user_upload/Rechtsgrundlagen/ Gesetze _Staatsvertraege/] MStV_Genese/] ugendm 
edienschutz-Staatsvertrag__JMStV__in_der Fassung _des_19. RA__StV.pdf 
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3.1.1.1 Erforderliche minimale Systemvoraussetzungen 


Die erforderlichen minimalen Systemvoraussetzungen, die für den Betrieb des 

Softwareprodukts Voraussetzung sind, müssen angegeben werden. 

e Minimal erforderliche Prozessor-Architektur inkl. Generation (z.B. Intel i5-3570k 3.4 GHz 4 
Core (64-Bit), Intel Atom x7-Z8700 Processor) 

e Minimal erforderlicher lokaler Arbeitsspeicher (MByte) 

e Minimal erforderlicher lokaler Permanentspeicher (MByte) 

e Erforderliche Voraussetzungen an weitere Software (Betriebssystem, Middleware und 
Hilfsanwendungen: Softwarestack) (z. B. Windows 7, .NET Framework und Browser 
Version XY) 

e Benennung der erforderlichen externen Dienste, die nicht auf dem Referenzsystem 
verfügbar sind (z. B. Cloud Dienste, Speicherdienste, API-Nutzung, ...) 

e Benennung erforderlicher zusätzlicher Hardware (z. B. Grafikkarte, Peripheriegeräte wie 
z.B. über USB angeschlossene Kamera). Voraussetzung ist, dass die zusätzliche Hardware 
direkt in das Referenzsystem (siehe Anhang D) integrierbar ist. 


Nachweis 


Der Antragsteller nennt die erforderlichen minimalen Systemvoraussetzungen in Anlage 1 zum 
Vertrag und trägt diese in die Tabellenkalkulationsdatei zur Kriterienerfassung in Anlage 2 zum 
Vertrag ein. 


3.1.1.2 Hardware-Auslastung und elektrische Leistungsaufnahme im Leerlauf 


Die Hardware-Auslastung und die elektrische Leistungsaufnahme, die durch den 
Leerlaufzustand des Softwareprodukts entsteht, müssen angegeben werden. Sie wird als 
Summe der zusätzlichen Auslastung der Hardware, die durch das Laden des Softwareprodukts 
entsteht, und einem prozentualen Anteil an der Grundauslastung bestimmt 
(Berechnungsvorschrift: siehe Anhang B). 


Folgende Angaben sind jeweils für den Leerlaufzustand des Softwareproduktes zu machen: 

e Mittlere Prozessorauslastung im Leerlauf (%) 

e Mittlere Arbeitsspeicherbelegung im Leerlauf (MByte) 

e Mittlere Permanentspeicherbelegung im Leerlauf (MByte/s) 

e Mittlere beanspruchten Bandbreite für Netzzugang im Leerlauf (Mbit/s) (umfasst nur die 
zusätzliche Auslastung, nicht zusätzlich den prozentualen Anteil an der Grundauslastung) 

e Mittlere elektrische Leistungsaufnahme (netto) (W) 


Nachweis 


Das Softwareprodukt muss auf einem Referenzsystem installiert und die Hardware-Auslastung 
entsprechend der im Anhang A beschriebenen Messmethodik bestimmt werden. Als 
Referenzsystem muss eines der im Anhang D genannten Computer-Systeme genutzt werden, 
wobei die Wahl des Systems und dessen Referenzjahr dem Antragsteller überlassen bleibt. Das 
genutzte Referenzsystem, der verwendete Softwarestack und vom Auslieferungszustand 
abweichende Konfigurationen (von Softwareprodukt und Softwarestack) müssen in der 
Tabellenkalkulationsdatei zur Kriterienerfassung in Anlage 2 zum Vertrag angegeben werden. 
Der Antragsteller nennt die Messwerte in Anlage 1 zum Vertrag und dokumentiert diese in der 
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Tabellenkalkulationsdatei in Anlage 2 zum Vertrag. Weiterhin legt er das Messprotokoll (vgl. 
Anhang A) als Anlage 3 zum Vertrag vor. 


3.1.1.3 Hardware-Inanspruchnahme und Energiebedarf bei Ausführung eines 
Standardnutzungsszenarios 


Die Hardware-Inanspruchnahme und der Energiebedarf bei Nutzung des Softwareprodukts zur 
Ausführung eines Standardnutzungsszenarios müssen angegeben werden 
(Berechnungsvorschrift: siehe Anhang B). 

Grundlage für die Berechnung sind Protokolldateien, die das Referenzsystem bei der 
Ausführung des Softwareproduktes aufzeichnet. Die Hardware-Inanspruchnahme beinhaltet 
dabei sowohl die zusätzliche Inanspruchnahme, die durch die Nutzung des Softwareprodukt 
entsteht, als auch einen prozentualen Anteil an der Grundauslastung (siehe dazu: Anhang B). 
Die Maßeinheiten für die Hardware-Inanspruchnahme sind Einheiten für Arbeitsleistung, 
wie %*s (Prozessorarbeit), MByte*s (Arbeitsspeicherarbeit), MByte/s*s = MByte (Permanent- 
speicherarbeit, Lesen und Schreiben) und MBit/s*s = MBit (im Netzwerk übertragene 
Datenmenge). 

Zusätzlich zur Hardware-Inanspruchhahme muss der elektrische Energiebedarf des 
Referenzsystems bestimmt werden. Die benötigte elektrische Energie ergibt sich durch 
Integration der elektrischen Leistungsaufnahme über die Ausführungsdauer des 
Standardnutzungsszenarios. Abweichend von den Festlegungen für die Hardware- 
Inanspruchnahme werden für die Messungen der elektrischen Energie nur die Leistungswerte, 
die über den elektrischen Grundverbrauch des Referenzsystems hinausgehen (Netto-Leistung), 
berücksichtigt (siehe dazu: Anhang B). 


Folgende Angaben sind jeweils bei Ausführung des Standardnutzungsszenarios unter 
Standardkonfiguration zu machen: 

e _Prozessorarbeit (%*s) 

e Arbeitsspeicherarbeit (MByte*s) 

e _Permanentspeicherarbeit (Lesen und Schreiben) (MByte/s*s) 

e _Übertragene Datenmenge für Netzzugang (Mbit/s*s) 

e Mittelwert des Energiebedarfs (netto) (Wh) 


Nachweis 


Die Messung erfolgt unter denselben Bedingungen, unter denen die Kriterien aus Abschnitt 
3.1.1.2 erfasst wurden. Der Antragsteller nennt die Messwerte in Anlage 1 zum Vertrag und 
dokumentiert diese in der Tabellenkalkulationsdatei in Anlage 2 zum Vertrag. Weiterhin legt er 
das Messprotokoll (vgl. Anhang A) als Anlage 3 zum Vertrag vor. 


3.1.1.4 Unterstützung des Energiemanagements 


Ein Softwareprodukt darf nicht voraussetzen, dass ein auf dem Rechner vorhandenes 
Energiemanagement-System (bspw. Standby-Modus/Ruhezustand) zu seinem reibungsfreien 
Betrieb deaktiviert/deinstalliertt werden muss. Das Energiemanagement des Rechners darf 
durch das Softwareprodukt nicht beeinträchtigt werden. Die Funktionalität des 
Softwareproduktes darf durch das Energiemanagement nicht beeinflusst werden (z. B. durch 
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eintretenden Datenverlust, Beeinträchtigung der Bedienbarkeit). Die Notwendigkeit einer 
(datenverlustfreien) Wiederanmeldung an eine serverbasierte Software oder die Zeit zum 
Reaktivieren des Computersystems aus einem Energiesparmodus wird nicht als 
Beeinträchtigung der Bedienbarkeit und Funktionalität gewertet. 


Folgende Anforderung muss erfüllt werden: 

Das Softwareprodukt muss bei aktiviertem Energiemanagement der darunterliegenden 
Systemschichten oder der verbundenen Clientsysteme uneingeschränkt funktional nutzbar 
sein. 


Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderung in Anlage 1 zum Vertrag. 


3.1.2 Potenzielle Hardware-Nutzungsdauer 


Eine Software darf nicht dazu beitragen, dass bestehende Hardware vorzeitig durch eine 
leistungsstärkere Hardware ersetzt werden muss, weil sie den Leistungsanforderungen der 
Software nicht gerecht wird. Software-Updates dürfen darüber hinaus nicht dazu führen, dass 
auch ein Hardware-Update erfolgen muss. Stattdessen muss dem Nutzenden eine voneinander 
unabhängige Entscheidung über Software- und Hardware-Erneuerung ermöglicht werden. Die 
Anforderungen innerhalb dieses Abschnitts adressieren deshalb die potenzielle Hardware- 
Nutzungsdauer. 


3.1.2.1 Abwärtskompatibilität 


Das Softwareprodukt muss auf einem Referenzsystem aus einem Kalenderjahr, das 
mindestens fünf Jahre vor Antragsstellung liegt, lauffähig sein. Der Anbieter des 
Softwareprodukts muss verbindlich erklären, mit welchem Referenzsystem aus welchem 
Kalenderjahr die Software noch lauffähig ist. Die Referenzsysteme sind hierbei ab dem Jahr 
2015 vorgegeben (siehe Anhang D). Der erforderliche Softwarestack (z. B. Betriebssystem, 
Framework, Anwendersoftware) und die Konfiguration von Softwareprodukt und Softwarestack 
müssen bei der Bestimmung dieser Jahreszahl berücksichtigt werden. 


Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderungen in Anlage 1 zum Vertrag durch 
Angabe des Kalenderjahrs des entsprechenden Referenzsystems inklusive des erforderlichen 
Softwarestacks und dokumentiert diese in der Tabellenkalkulationsdatei in Anlage 2 zum 
Vertrag ("Abwärtskompatibilitätssystem"). 


3.1.3 Nutzungsautonomie 


Ein Softwareprodukt soll die Autonomie des Nutzenden im Umgang mit dem Produkt nicht 
einschränken und es soll keine Anhängigkeit schaffen. Die nachfolgend genannten 
Anforderungen tragen zu unterschiedlichen Aspekten der Nutzungsautonomie bei. 


3.1.3.1 Datenformate 


Damit die Interoperabilität des Softwareproduktes ermöglicht wird, müssen die Datenformate 
(Datei- und Datenstromformate), die das Softwareprodukt zur Ablage der von Nutzenden 
erzeugten Daten oder zum Austausch von Daten mit anderen Programmen verwendet, 
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ausreichend dokumentiert sein. Die Datenformate müssen offengelegt werden, so dass eine 
Weiternutzung der Daten mit einem anderen Softwareprodukt möglich ist um somit dem 
Grundgedanken dieses Blauen Engel zur Auszeichnung von Produkten, deren Hersteller 
besonders transparent arbeiten, zu fördern (vgl. Abschnitt 1.2). 


Die Dokumentation der Datenformate muss über eine der folgenden Möglichkeiten erfolgen: 

e Vorlage der Handbücher oder technischer Datenblätter, in denen die Datenformate 
dokumentiert sind oder 

e Beispielhafte Nennung weiterer Softwareprodukte (anderer Anbieter), die diese 
Datenformate verarbeiten können oder 

e Benennung der Datenformate und Zuordnung zu einem offenen Standard. 


Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderungen in Anlage 1 zum Vertrag durch eine 
der oben genannten Möglichkeiten und legt entsprechende Nachweisdokumente als Anlage 4 
zum Vertrag vor. 


3.1.3.2 Transparenz des Softwareprodukts 


Zur Erweiterung des Softwareproduktes um zusätzliche Funktionalitäten müssen die 
Anwendungs-Programmier-Schnittstellen (APIs) klar dokumentiert sein. Die APIs sollen offenen 
Standards entsprechen. 

Im Sinne einer langfristigeren bzw. umfangreicheren Nutzung soll idealerweise außerdem der 
Quellcode ganz oder teilweise offengelegt werden, spätestens wenn das Produkt nicht 
weiterentwickelt wird, sowie die Erlaubnis dazu erteilt werden, das Produkt zu verändern. 


Folgende Angaben müssen gemacht werden: 

e Sofern Anwendungs-Programmier-Schnittstellen vorhanden sind: Vorlage der 
Schnittstellendokumentation. 

e Angabe, in welchem Umfang Programmbestandteile mit dokumentiertem Quellcode 
offengelegt werden, bzw. ob das gesamte Softwareprodukt als offener Quellcode 
bereitgestellt wird. Falls der Quellcode des Softwareprodukts offengelegt wird, muss 
angegeben werden, wie auf den Quellcode zugegriffen werden kann (bspw. über gängige 
Quellcode-Verwaltungsplattformen wie GitHub, GitLab, Bitbucket, Sourceforge etc.) 

e Erklärung, was mit dem Softwareprodukt nach Supportende geschieht, d. h. wenn das 
Produkt bzw. die zertifizierte Version des Produktes nicht mehr erworben werden kann 
und/oder für die Nutzung des Produktes bzw. für die Version des Produktes kein Support 
mehr besteht (bspw. Offenlegung und freie Lizensierung des eigenen Quellcodes, weiterer 
Support für Nutzende durch Dritte, Escrow Vertrag, ...) 

e Nennung der Lizenz, unter der das Softwareprodukt vertrieben wird und der Rechte, die 
die Lizenz einräumt inkl. Angabe dazu, ob das Softwareprodukt durch Dritte 
weiterentwickelt werden darf. 

e Nennung der Lizenzen aller Software-Bestandteile, sofern sie sich von der Lizenz, unter 
der das Softwareprodukt vertrieben wird, unterscheiden. 


Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderungen in Anlage 1 zum Vertrag und legt 
entsprechende Nachweisdokumente (Schnittstellendokumentation, Permalink der 
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Softwarequelle auf einer Quellcode-Verwaltungsplattform, Softwarelizenzen oder vergleichbar) 
als Anlage 5 zum Vertrag vor. 


3.1.3.3 Kontinuität des Softwareproduktes 


Es muss möglich sein, das Softwareprodukt über einen längeren Zeitraum zu nutzen, ohne 
dass schwerwiegende Nachteile (insbesondere Probleme der IT-Sicherheit) auftreten. Dazu 
muss der Softwarehersteller eine Funktionalität anbieten, mit der das Softwareprodukt auf 
dem aktuellen Stand gehalten werden kann. Sicherheitsupdates müssen kostenlos erfolgen, 
Updates mit zusätzlicher Funktionalität sind davon ausgeschlossen. Der Antragsteller 
verpflichtet sich dazu, Sicherheitsupdates für das zu kennzeichnende Produkt für mindestens 5 
Jahre ab Bereitstellungsende anzubieten. 

Bei der Bereitstellung von Software-Updates durch den Anbieter muss der Anwender die Wahl 
haben, ob nur Sicherheitsupdates oder auch sonstigen (z. B. funktionelle) Updates installiert 
werden sollen. Generell sind bei der Update-Bereitstellung die in Abschnitt 3.2 formulierten 
Anforderungen während der Vertragslaufzeit zum Umgang mit Updates zu berücksichtigen. 


Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderungen in Anlage 1 zum Vertrag, markiert 
die entsprechenden Stellen der Produktinformationen, in denen auf die Software-Updates 
hingewiesen wird und legt die betreffenden Seiten der Produktinformationen als Anlage 6 zum 
Vertrag vor. 


3.1.3.4 Deinstallierbarkeit 


Ein Softwareprodukt muss am Ende seiner Nutzungsdauer rückstandsfrei von dem 
Computersystem entfernt werden können und darf keine unnötigen Datenspuren hinterlassen. 
Die durch den Nutzer mit dem Softwareprodukt erstellten und bearbeiteten Daten sind hiervon 
ausgenommen und dürfen auch bei Deinstallation des Softwareprodukts nicht automatisch 
gelöscht werden (Ausnahme: der Nutzer bestätigt die Löschung). Hierzu muss das 
Softwareprodukt inklusive der ggf. durch die Software zusätzlich installierten Komponenten 
oder Bibliotheken durch den Nutzenden (bzw. den Systemadministrator) einfach und ohne 
großen zeitlichen Aufwand deinstallierbar sein. 

In den Produktinformationen muss das Vorgehen zur Deinstallation erläutert werden. 


Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderungen in Anlage 1 zum Vertrag, markiert 
die entsprechenden Stellen in den Produktinformationen, in denen auf die Deinstallation 
hingewiesen wird und legt die betreffenden Seiten der Produktinformationen als Anlage 6 zum 
Vertrag vor. 
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3.1.3.5 Offlinefähigkeit 


Die Funktionalität und Verfügbarkeit einer Software dürfen nicht durch externe Faktoren, wie 
beispielsweise die Verfügbarkeit eines Lizenzservers, beeinträchtigt werden. 

Das Softwareprodukt muss dazu weitgehend auch ohne eine Netzwerkanbindung (offline) 
funktionsfähig sein, sofern diese nicht explizit für dessen Funktionserfüllung erforderlich sind. 
Wenn eine Netzwerkanbindung notwendig ist, ist darauf in den Produktinformationen 
hinzuweisen und die Notwendigkeit der Netzwerkanbindung zu begründen. In allen Fällen muss 
eine Offline-Nutzung des Produktes möglich sein (ggf. eingeschränkt). 


Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderungen in Anlage 1 zum Vertrag, markiert 
die entsprechenden Stellen in den Produktinformationen, in denen auf die Offlinefähigkeit 
hingewiesen wird und legt die betreffenden Seiten der Produktinformationen als Anlage 6 zum 
Vertrag vor. 


3.1.3.6 Modularität 


Durch modulare Installation des Softwareprodukts, das neben der Hauptfunktion weitere, nicht 
zwingende, Funktionen anbietet, kann der Speicher- und Energiebedarf reduziert werden. Das 
Softwareprodukt soll den Nutzenden die Möglichkeit anbieten die Funktionalität auf den 
gewünschten Funktionalitätsumfang zu beschränken. 


Folgende Angaben müssen gemacht werden: 

e Angabe, inwiefern beim Installationsprozess einzelne Module des Softwareproduktes 
deaktiviert werden können. 

e Angabe, inwiefern während der Nutzung einzelne Module, insbesondere diejenigen, die 
nicht zu den Funktionalitäten des Softwareprodukts gehören (bspw. Tracking etc.), des 
Softwareproduktes deaktiviert werden können. 


Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderungen in Anlage 1 zum Vertrag, markiert 
die entsprechenden Stellen in den Produktinformationen, in denen auf die Modularität 
hingewiesen wird und legt die betreffenden Seiten der Produktinformationen als Anlage 6 zum 
Vertrag vor. 


3.1.3.7 Werbefreiheit 


Durch die Einblendung von Werbung kann der Ressourcen- und Energiebedarf durch 
Softwareprodukte erhöht werden. Insbesondere kann die Einblendung von Werbung, bspw. 
über einen externen Dienstleister, eine Übertragung zusätzlicher Datenmengen vom Client zum 
Server und umgekehrt bedeuten. Dieser Netzwerkverkehr hat für die direkte Funktionalität des 
Softwareproduktes keine Bedeutung und sollte vermieden werden. Daher müssen 
Softwareprodukte, die mit dem Umweltzeichen ausgezeichnet werden, werbefrei sein. Davon 
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ausgenommen sind Werbungen für das eigene Unternehmen, weitergehende Versionen der 
Software oder anderer Software des gleichen Herstellers. 


Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderung in Anlage 1 zum Vertrag. 


3.1.3.8 Dokumentation des Softwareprodukts, der Lizenz- und 
Nutzungsbedingungen 


Das Softwareprodukt muss mit einer Dokumentation versehen sein, die eine langfristige und 
ressourcenschonende Nutzung des Produktes ermöglicht. Der Antragsteller muss 
entsprechende Informationen zum Softwareprodukt sowohl öffentlich als auch zusammen mit 
dem Produkt selbst zur Verfügung stellen. 


Folgende Nutzungsinformationen müssen in der Dokumentation enthalten sowie in den 

einschlägigen Produktinformationen (Handbuch, Website, etc.) verfügbar sein: 

a) Beschreibung der Installation und der Deinstallation 

b) Beschreibung von Datenimport und -export 

c) Informationen zur Reduzierung von Ressourceninanspruchnahme (z. B. Aktivierung von 

Energiesparmodi, Deaktivierung nicht genutzter Module, Beeinflussung der Größe von 

Auslagerungsdateien, Bereinigung von Datenresten) 

d) Angaben zu den Lizenz- und Nutzungsbedingungen, sodass ggf. eine rechtssichere 

Weiterentwicklung des Softwareproduktes ermöglicht wird 

e) Angaben über Software-Support 

f) Angaben zum Umgang mit Daten im Sinne bestehender Datenschutzgesetze. Dies gilt auch 

dann, wenn Dienste oder Teile davon auf Servern außerhalb des deutschen oder europäischen 

Rechtsraumes betrieben oder bereitgestellt werden. 

g) Angaben zur Datensicherheit, -erhebung und -übertragung: 

e Angabe, inwiefern beim Installationsprozess einzelne Module der Software deaktiviert 
werden können. 

e Angabe, inwiefern während der Nutzung einzelne Module, insbesondere diejenigen, die 
nicht zu den Funktionalitäten der Software gehören (bspw. Tracking, Werbung, etc.), der 
Software deaktiviert werden können. 

e Erklärung, dass Daten nur in dem Umfang erhoben bzw. gespeichert werden, wie sie zur 
unmittelbaren Erfüllung der Funktionalität der Software erforderlich sind. 

e Bestätigung, dass die Software-Nutzenden über die Art, Umfang, Dauer der Speicherung 
sowie den Verwendungszweck der erhobenen Daten aufgeklärt werden und eine 
Einverständniserklärung eingeholt wird. 

e Erklärung, dass eine Weitergabe von Daten an Dritte nur nach ausdrücklicher Zustimmung 
der Nutzenden und nur im funktionell erforderlichen Umfang erfolgt. 

e Bestätigung, dass keine Verwendung der erhobenen Daten für Werbezwecke erfolgt. 

e Bestätigung, dass nach Nutzungsende der Software nicht mehr erforderliche Daten 
unmittelbar und dauerhaft gelöscht werden. 
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Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderungen in Anlage 1 zum Vertrag, markiert 
die entsprechenden Stellen in den Produktinformationen und legt die betreffenden Seiten der 
Produktinformationen als Anlage 6 zum Vertrag vor. Er erklärt sich zudem bereit, dass die 
Inhalte der Tabellenkalkulationsdatei zur Kriterienerfassung (Anlage 2) auf der Internetseite 
des jeweiligen Produktes veröffentlicht werden und liefert die darin enthaltenen Daten in einem 
definierten Datenformat (siehe Anhang C) als Anlage 7 aus. 


3.2 Anforderungen während der Vertragslaufzeit 


3.2.1 Anforderungen an Weiterentwicklung und Updates des Produktes 


Bei Änderung des Produktes (bspw. durch Updates) ist sicherzustellen, dass alle Kriterien 
weiterhin durch den Antragssteller eingehalten werden. Änderungen dürfen nicht dazu führen, 
dass die Hardware zur weiteren Nutzung der Software ausgetauscht werden muss. Die 
Software muss auch nach einem Update mit demselben Standardnutzungsszenario auf 
demselben Referenzsystem lauffähig sein, das bei Antragsstellung verwendet wurde, und 
ebenso auf dem Referenzsystem, das fünf Jahre vor der Antragstellung gültig war. Ist dies 
nicht der Fall, ist eine erneute Beantragung des Blauen Engel notwendig. 

Für die Werte des Energiebedarfs ist eine Ausnahme möglich: Der Energiebedarf darf sich nicht 
um mehr als 10% gegenüber den Werten bei Antragsstellung erhöhen, andernfalls sind die 
Gründe für die Veränderung aufzuführen und der RAL gGmbH zu melden. Der Wert des 
Energiebedarfs muss nach einem Update auf dem Referenzsystem erhoben werden, das auch 
bei Beantragung des Blauen Engel genutzt wurde. 


Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderungen in Anlage 1 zum Vertrag. Er 
aktualisiert die Tabellenkalkulationsdatei zur Kriterienerfassung (Anlage 2) und Informationen, 
die auf der Produktwebsite zur Verfügung gestellt werden sowie Anlage 7 entsprechend der 
neuen Werte. 


3.3 Anforderungen zum Ende der Vertragslaufzeit 


3.3.1 Abschlussevaluation 


Der Zeichennehmer muss der RAL gGmbH zum Ende der jeweiligen Vertragslaufzeit einen 
Ressourceneffizienzbericht vorlegen. In diesem Bericht sind die während der Vertragslaufzeit 
gemessenen Werte (Bereich "3.1 Ressourcen- und Energieeffizienz", beispielsweise bei 
Updates) darzustellen. Die Maßnahmen, die zur Erhöhung der Ressourcen- und 
Energieeffizienz der Software während der Vertragslaufzeit getroffen wurden, sind zu 
beschreiben. 

Sofern der Zeichennehmer seiner Verpflichtung zur Vorlage Ressourceneffizienzberichtes nicht 
nachkommt oder der Bericht dokumentiert, dass Anforderungen des Blauen Engel an das 
Softwareprodukt nicht eingehalten wurden, stellt dies einen Verstoß gegen den 
Zeichenbenutzungsvertrag (siehe Abschnitt 5) dar und kann seitens der RAL gGmbH mit dem 
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Entzug der Erlaubnis zur Zeichenbenutzung sanktioniert werden. Eine erneute Beantragung 
bzw. Verlängerung des Blauen Engel für das bzw. ein gleichnamiges Softwareprodukt ist dann 
auch mit anderen Versionen / Updates nicht möglich. 


Nachweis 


Der Antragsteller erklärt die Einhaltung der Anforderungen in Anlage 1 zum Vertrag. Zum Ende 
der Vertragslaufzeit legt er einen Ressourceneffizienzbericht vor. Für den Bericht kann der 
Antragssteller die Tabellenkalkulationdatei zur Kriterienerfasssung ergänzt um eine 
Beschreibung der getroffenen Maßnahmen zur Ressourceneffizienz heranziehen. Die Werte zu 
den Anforderungen aus dem Bereich 3.1.1 Ressourcen- und Energieeffizienz müssen enthalten 
sein. 


4 Zeichennehmer und Beteiligte 


Zeichennehmer sind Hersteller oder Vertreiber von Softwareprodukten. Bei arbeitsteilig 
hergestellter Software (beispielsweise bei Freier Software) kann ein einzelnes Unternehmen 
oder eine juristische Person als Zeichennehmer auftreten. Bei Updates des zertifizierten 
Produktes ist zu prüfen, ob eine erneute Antragsstellung notwendig ist (vgl. 
Begriffsbestimmungen und Abschnitt 3.2). 


Beteiligte am Vergabeverfahren: 

e RAL gGmbH für die Vergabe des Umweltzeichens Blauer Engel, 

e das Bundesland, in dem sich die Produktionsstätte des Antragstellers befindet, 

e das Umweltbundesamt, das nach Vertragsschluss alle Daten und Unterlagen erhält, die zur 
Beantragung des Blauen Engel vorgelegt wurden, um die Weiterentwicklung der 
Vergabekriterien fortführen zu können. 


5 Zeichenbenutzung 


Die Benutzung des Umweltzeichens durch den Zeichennehmer erfolgt aufgrund eines mit der 
RAL gGmbH abzuschließenden Zeichenbenutzungsvertrages. 


Im Rahmen dieses Vertrages übernimmt der Zeichennehmer die Verpflichtung, die 
Anforderungen gemäß Abschnitt 3 für die Dauer der Benutzung des Umweltzeichens 
einzuhalten. 


Für die Kennzeichnung von Produkten gemäß Abschnitt 2 werden Zeichenbenutzungsverträge 
abgeschlossen. Die Geltungsdauer dieser Verträge läuft bis zum 31.12.2023. 

Sie verlängert sich jeweils um ein weiteres Jahr, falls der Vertrag nicht bis zum 31.03.2023 
bzw. 31.03. des jeweiligen Verlängerungsjahres schriftlich gekündigt wird. 

Eine Weiterverwendung des Umweltzeichens ist nach Vertragsende weder zur Kennzeichnung 
noch in der Werbung zulässig. Noch im Handel befindliche Produkte bleiben von dieser 
Regelung unberührt. 


Der Zeichennehmer kann die Erweiterung des Benutzungsrechtes für das 
Kennzeichnungsberechtigte Produkt bei der RAL gGmbH beantragen, wenn es unter einem 
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anderen Marken-/Handelsnamen und/oder anderen Vertriebsorganisationen in den Verkehr 
gebracht werden soll. 


In dem Zeichenbenutzungsvertrag ist festzulegen: 
e _Zeichennehmer (Hersteller/Vertreiber) 


e _Marken-/Handelsname, Produktbezeichnung 
e _Inverkehrbringer (Zeichenanwender), d. h. die Vertriebsorganisation. 


© 2020 RAL gGmbH, Bonn 
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Anhang A Messanleitung für die Kriterien 3.1.1.2 und 3.1.1.3 


Im Folgenden wird eine Anleitung zu einer möglichen Durchführung von Softwaremessungen 
zur Erfassung von Energieverbrauchsdaten und Hardware-Auslastung gegeben. 


Diese Anleitung ist eine exemplarische Vorgehensweise zur Erfassung von Verbrauchsdaten. 
Die Schritte wurden mit den Betriebssystemen Windows 7, Windows 10, Ubuntu 16.04 und 
Ubuntu 18.04 getestet und sind analog auf weitere Betriebssysteme übertragbar. 


1 


Ablauf der Messungen 


Zur Bestimmung des durch das Softwareprodukt zusätzlich erzeugten Energieverbrauchs und 
der zusätzlichen Hardware-Auslastung müssen 3 Messungen durchgeführt werden: 


2 


Messung der Grundauslastung 
Messung der Leerlaufauslastung 
Messung der Auslastung bei Ausführung des Standardnutzungsszenarios 


generelle Ablauf der Messungen ist wie folgt: 

Zur Messung der Grundauslastung wird das Betriebssystem, sowie der notwendige 
Softwarestack auf dem Referenzsystem installiert. Software-Bestandteile die zusammen 
mit dem Softwareprodukt ausgeliefert werden (z.B. eine zusammen mit dem 
Softwareprodukt ausgelieferte Java Runtime, Datenbank o.Ä.) sind hiervon 
ausgeschlossen. Falls benötigt, wird außerdem noch eine Automatisierungssoftware (s.u.) 
installiert. Dieses System wird, wie in der Messanleitung beschrieben, gemessen. Dabei 
wird außer dem Betriebssystem und einer ggf. notwendigen Automatisierungssoftware 
(s.u.) keine weitere Software gestartet. 

Zur Messung der Auslastung im Leerlauf wird zusätzlich zu den Komponenten der Messung 
der Grundauslastung auch das zu zertifizierende Softwareprodukt installiert und gestartet. 
Nach dem Starten wird das System wie unten angegeben gemessen. 

Zur Messung der Auslastung bei Ausführung des Standardnutzungsszenarios ist die 
installierte Software identisch mit dem System zur Messung der Leerlaufauslastung. Zur 
Messung wird das Softwareprodukt sowie ggf. die Automatisierungssoftware gestartet und 
das Standardnutzungsszenario automatisiert abgespielt. Währenddessen wird die 
Auslastung wie unten angegeben gemessen. 

Nachdem die Messung beendet ist, werden die generierten Dateien ausgewertet. 


Notwendiges Equipment zur Messung 


Um eine Messung durchzuführen, wird folgendes Equipment benötigt: 


SUT - System Under Test 

Leistungsmessgerät 

Rechner zum Auslesen des Leistungsmessgeräts und zur Berechnung der mittleren 
Hardwareauslastung und des Energieverbrauchs (s.u.) 
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3 Statistische Signifikanz der Messungen 


Damit valide statistische Auswertungen der Messungen ausgeführt werden können, ist es 
wichtig, die gleiche Messung mehrmals hintereinander auszuführen. Dies kann automatisiert 
durch eine Software erfolgen, die Makro-Befehle aufzeichnet oder ein dazu entwickeltes Skript 
oder Programm, das ein Szenario wiederholt auf dem Referenzsystem abspielen kann. 

Durch diese Messungen kann ermittelt werden, ob sich die Stromverbräuche der verschiedenen 
Messungen signifikant voneinander unterscheiden (bspw. nach Updates). Die Messungen 
können ebenso für Entwickler* innen von Software nützliche Informationen darüber liefern, wie 
sich unterschiedliche Prozeduren oder Architekturen auf den Energie- und 
Ressourcenverbrauch auswirken. Um das Risiko zufälliger Ausreißer bei den Messungen zu 
minimieren, müssen die Messungen mit mindestens 10 Durchläufen wiederholt werden, 
empfohlen werden mindestens 30 Durchläufe. 


4 Vorbereitende Arbeiten 


Bevor die Messung der Software gestartet werden kann, sind vorbereitende Maßnahmen 

durchzuführen: 

e  Zeitsynchronisation: Damit eine valide Messung durchgeführt werden kann, müssen die 
Uhrzeiten von Leistungsmessgerät, Referenzsystem, sowie ggf. weiterer Hardware 
übereinstimmen. 

e Für die Messung von Leerlaufauslastung und Standardnutzungsszenario ist zusätzlich die 
Installation des zu zertifizierenden Softwareproduktes notwendig. 

e Aufzeichnung des Standardnutzungsszenarios. 


5 Aufzeichnung des Standardnutzungsszenarios 


Zur automatischen Aufzeichnung von manuellen Nutzereingaben am Computer werden 
Makrorecorder (z.B. WinAutomation’, Pulover's Macro Creator?) genutzt, die eine Abfolge von 
Aktionen aufzeichnen, die ein Nutzender typischerweise durch Mausklicks und mit 
Tastatureingaben an der zu zertifizierenden Software ausführt. Diese Aktionen können zum 
einen direkt durch Starten eines Aufnahmemodus erfasst werden und zum anderen durch 
manuelle Eingabe erstellt und bearbeitet werden. Ob lediglich eine Möglichkeit der genannten 
Aufzeichnungsmethoden besteht oder beide angeboten werden, hängt von der jeweiligen 
Software ab. 

Alternativ zu dieser Aufzeichnungssoftware können zur Erstellung des automatisierten 
Standardnutzungsszenarios auch Skripte oder Eigenentwicklungen genutzt werden. Wichtig ist, 
dass bei jeder Messung (Grundauslastung, Leerlauf und Standardnutzungsszenario) dieselbe 
Software verwendet wird um Messfehler durch die Automatisierungssoftware zu minimieren. 
Das Ergebnis der Aufzeichnung ist z. B. eine ausführbare Datei oder ein Skript, das die 
Nutzereingaben zusammenführt und so das Standardnutzungsszenario automatisch ablaufen 
lassen kann. Es wird empfohlen durch die Automatisierungssoftware zusätzlich eine Log-Datei 
erstellen zu lassen, in der die Zeitstempel zu Beginn und Ende der einzelnen Messungen 
aufgezeichnet werden. 





https: //www.winautomation.com/ 


$ https: //www.macrocreator.com/ 
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6 Werkzeuge zur Ermittlung von Leistungsindikatoren 


Neben den Energiewerten, die durch ein Strommessgerät erfasst werden, müssen zusätzliche 
Indikatoren (Prozessorauslastung, RAM-Belegung, Festplattenaktivität und Netzwerktraffic) 
gemessen werden. Hierzu wird eine weitere Software benötigt, die Leistungsdaten erfassen 
und den aktuellen Systemstatus aufzeichnen kann (z. B. Windows Performance Monitor?, 
Collectl!°). Hier wird ebenfalls empfohlen, durch die Software eine Log-Datei mit den 
gemessenen Daten und Zeitstempel erstellen zu lassen. Außerdem wird empfohlen mindestens 
sekündliche Messpunkte zu wählen. 


7 Aufzeichnung der elektrischen Leistungsaufnahme 


Zur Messung der elektrischen Leistungsaufnahme wird ein Messgerät (z.B. Janitza UMG 604, 
Gude Expert Power Control 1202) benötigt, das die elektrische Leistungsaufnahme über den 
Zeitraum der Messungen aufzeichnen kann. Es wird empfohlen ein Messgerät zu verwenden, 
mit dem die gemessene Leistungsaufnahme über eine Sekunde aggregiert und zusammen mit 
einem Zeitstempel in einer Log-Datei abgespeichert werden kann. 


8 Ablauf der Leistungs- und Energiemessung des Nutzungsszenarios 


Nachdem die vorbereitenden Schritte durchgeführt wurden (vgl. Abschnitte 4 und 5 des 

Anhang A), wird die Energie- und Leistungsmessung gestartet. 

e Das Tool zur Leistungsüberwachung (s. Abschnitt 6, Anhang A) wird gestartet. 

e Die Messung der elektrischen Leistung wird gestartet. 

e Die Datei, die durch die Makro-Recording-Software generiert wurde, bzw. die 
Automatisierungssoftware oder das Automatisierungsskript, wird gestartet. 

e Bis die Messung beendet ist, darf nicht eingegriffen werden, um die Messergebnisse nicht 
zu verfälschen. 

e Die Leistungsdatenüberwachung wird nach Durchlaufen des Standardnutzungsszenarios 
gestoppt. 


9 Daten auslesen 


Die Messung ist nun abgeschlossen. Zu diesem Zeitpunkt empfiehlt es sich, die Rohdaten der 
Messungen gesammelt an einem Speicherort abzulegen. Im nächsten Schritt werden die 
aufgenommenen Daten ausgewertet (siehe Anhang B). 


?  https://techcommunity.microsoft.com/t5/Ask-The-Performance-Team/Windows-Performance-Monitor- 
Overview/ba-p/375481 
10 http://collectl.sourceforge.net/ 
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Anhang B Hinweise zur Erfassung der Kriterien 


1 Grundlegende Definitionen 


Für die Messung der Indikatoren in den Abschnitten 3.1.1.2 und 3.1.1.3 gelten folgende 


grundlegenden Definitionen: 


Tabelle 1: 
3.1.1.3) 


Bezei- 
chner 
VAi 


GAi 


NLAI 


BAI 


NAi 


AFi 


Grundlegende Definitionen für die Messung des Softwareprodukts (3.1.1.2 und 


Name 


Vollauslastung 


Grundauslastung 


Leerlauf-Auslastung 


Netto- Leerlauf- 
Auslastung 


Ausführungsdauer 


Brutto-Auslastung 


Netto-Auslastung 


Allokationsfaktor 


Anhang B 


Definition 


Obere Grenze der Auslastung i des 
Referenzsystems 


Messwert der mittleren Auslastung 
i des Referenzsystems ohne das 
Softwareprodukt. 


Messwert der mittleren Auslastung 
i des Referenzsystems im Leerlauf 
des Softwareprodukts 


NLAi = LAi - GAi 


Laufzeit des Softwareprodukts bei 
Ausführung des 
Standardnutzungsszenarios auf 
dem Referenzsystem 


Mittlere Auslastung des 
Referenzsystems bei Ausführung 
eines Standardnutzungsszenarios 
über dessen Ausführungsdauer 
NAi = BAi - GAi 


AFi = NAi / (VAi - GAi) 
(Allokationsfaktor für die 
Ausführung des 
Standardnutzungsszenarios) 
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Anmerkung 


Bei Prozessorleistungen beträgt 
die Vollauslastung 100%, bei 
Arbeitsspeicher die Summe der 
installierten RAM-Kapazitäten, 
beim Netzwerk die maximale 
Übertragungsgeschwindigkeit usw. 
Dieser Wert stellt einen 
konstanten Wert des 
Referenzsystems dar. 


Sie beinhaltet sowohl die 
Grundauslastung (GAi) als auch 
die zusätzliche durch den 
Leerlaufbetrieb der Software 
verursachte Hardware-Auslastung. 
Sie beschreibt die 
Leerlaufauslastung der Software 
ohne den Anteil der 
Grundauslastung (GAi). 

Sie beginnt mit dem Start des 
Standardnutzungsszenarios und 
endet mit der Erledigung aller dort 
vorgesehenen Aktionen, inklusive 
nachgelagerter Prozesse (z.B. 
Freigeben von Arbeitsspeicher, 
Löschung temporärer Dateien). 
Sie wird als zeitgewichteter 
Mittelwert der Messwerte über die 
Ausführungsdauer berechnet. 


Sie bezeichnet die durch das 
Softwareprodukt verursachte 
mittlere Hardware-Auslastung 
nach Abzug der Grundauslastung 
des Referenzsystems. 

Verhältnis der durch das 
Softwareprodukt beanspruchten 
Netto-Auslastung zu der maximal 
zur Verfügung stehenden 
Auslastung. Dabei ist 
berücksichtigt, dass maximal nur 
die Differenz zwischen der 
Vollauslastung (VA) und der 
Grundauslastung (GA) zur 
Verfügung steht. Dieser Faktor 
wird zur Berechnung der 
Effektiven Auslastung (EAi) 
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AFLi 


EAi 


ELAi 


Hi 


Die 


Leerlauf-Allo- 
kationsfaktor 


Effektive Auslastung 


Effektive Leerlauf- 
Auslastung 


Hardware- 
Inanspruchnahme 


AFLi = NLAi / (VAi - GAi) 
(Allokationsfaktor für den Leerlauf 
der Software) 


EAi = NAi + AFi * GAi 


ELAI = NLAi + AFLi * GAi 


Hi = EAi * t 


nachfolgende Abbildung stellt den Messzyklus beispielhaft dar 


verschiedenen Auslastungen und deren Bezeichnung. 


benötigt. 


Anteil der Netto- Leerlauf- 
Auslastung (NLAi) zur gesamten 
zur Verfügung stehenden Leistung 
(Vai - GAi). Dieser Faktor wird zur 
Berechnung der Effektiven 
Leerlauf-Auslastung (ELAi) 
benötigt. 

Die Effektive Auslastung wird 
berechnet als Summe aus Netto- 
Auslastung (NAi) und einem Anteil 
an der Grundauslastung (GAi), der 
über den Allkokationsfaktor (AFi) 
bestimmt wird. 

Die Effektive Leerlauf-Auslastung 
wird berechnet als Summe aus 
Netto-Leerlauf-Auslastung (NLAi) 
und einem Anteil an der 
Grundauslastung (GAi), der über 
den Leerlauf-Allkokationsfaktor 
(AFLi) bestimmt wird. Siehe 
Abschnitt 3.1.1.2. 

Die Hardware-Inanspruchnahme 
ist das Produkt der Effektiven 
Auslastung (EAi) und der 
Ausführungsdauer (t). Ihre 
Einheiten sind beispielsweise 
Prozentsekunden (%s), 
Megabytesekunden (MByte*s), 
Megabyte (MByte/s*s) und 
Megabit (MBit/s*s). Siehe 
Abschnitt 3.1.1.3. 


und illustriert die 


Abb. 1: Beispielhafter Messzyklus zur Bestimmung der Hardware-Auslastung 


Anhang B 
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==> t1: Start der Software-Ausführung des Standardnutzungsszenarios 
= t2: Abschluss der Software-Ausführung des Standardnutzungsszenarios 
== -= - Grundlauslastung (GA) des Referenzsystems ohne die zu untersuchende Software 


un Hardware-Auslastung im Leerlauf (LA) der untersuchten Software 





Gemessene Hardware-Auslastung bei Ausführung des Standardnutzungsszenarios 
— - - Brutto-Auslastung (BA) während der Ausführungsdauer (Mittelwert der Messwerte) 
Netto-Auslastung (NA) während der Ausführungsdauer (NA = BA - GA) 
----- Effektive Auslastung (EA) während der Ausführungsdauer (EA = NA + af * GA) 
Quelle: Abschlussbericht zum Projekt „Entwicklung und Anwendung von 
Bewertungsgrundlagen für ressourceneffiziente Software unter Berücksichtigung bestehender 
Methodik (UFOPLAN-SSD-2015) 


2 Hinweise zur Erfassung der Grundauslastung 


Die Hardware-Auslastung und die elektrische Leistungsaufnahme, die durch den Betrieb des 
Systems ohne installiertes Softwareprodukt (Grundauslastung) entsteht, wird zur Bestimmung 
der Indikatoren in den Abschnitten 3.1.1.2 und 3.1.1.3 benötigt. Zur Messung der 
Grundauslastung wird auf dem Referenzsystem sämtliche zum Betrieb des Softwareprodukts 
notwendige Software (Betriebssystem, Softwarestack) installiert, nicht jedoch das eigentliche 
Softwareprodukt und auch keine Software-Bestandteile, die mit dem Softwareprodukt 
ausgeliefert werden. Außer dem Betriebssystem und einer ggf. notwendigen 
Automatisierungssoftware werden keine weiteren Anwendungen gestartet. Anschließend wird 
die Hardware-Grundauslastung, sowie die elektrische Leistungsaufnahme entsprechend der im 
Anhang A beschriebenen Messmethodik bestimmt. Als Referenzsystem ist eines der im 
Anhang D genannten Systeme zu nutzen. 


3 Hinweise zur Erfassung der Hardware-Auslastung im Leerlauf (Kriterium 3.1.1.2) 


3.1 Messkonzept: Hardware-Auslastung im Leerlauf 


Die Hardware-Auslastung, die durch den Leerlauf des Softwareprodukts entsteht, muss 
angegeben werden. Hierzu muss die Software auf einem Referenzsystem installiert und die 
Hardware-Auslastung im Leerlauf entsprechend der im Anhang A beschriebenen Messmethodik 
bestimmt werden. Als Referenzsystem ist eines der im Anhang D genannten Systeme zu 
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nutzen. Das genutzte System ist in der Tabellenkalkulationsdatei zur Kriterienerfassung 
(Anlage 2) anzugeben. 

Die Hardware-Auslastung im Leerlauf beinhaltet dabei die zusätzliche Auslastung, die durch 
das Aktivieren des Softwareprodukt entsteht, als auch einen prozentualen Anteil an der 
Grundauslastung. Als mittlere elektrische Leistungsaufnahme (in Watt) wird der Mittelwert 
über alle Messungen der Leistungsaufnahme im Leerlauf gebildet 


3.2 Vorgehen zur Erfassung der Hardware-Auslastung im Leerlauf 


Das zu messende Softwareprodukt wird auf einem Referenzsystem installiert. Das genutzte 
Referenzsystem, der verwendete Softwarestack und vom Auslieferungszustand abweichende 
Konfigurationen (von Softwareprodukt und Softwarestack) müssen dokumentiert werden 
(siehe Nachweis des Kriteriums 3.1.1.2). 

Danach wird das Softwareprodukt gestartet und die Messung der Hardwareauslastung des SUT 
durchgeführt. Die Messungen müssen mit mindestens 10 Durchläufen wiederholt werden, 30 
Messdurchläufe werden empfohlen (vgl. Anhang A, Abschnitt 3), ein Durchlauf des 
Standardnutzungsszenarios muss mindestens 5 Minuten dauern (vgl. Anhang D, Abschnitt 2), 
erfasst wird 1 Messwert pro Sekunde, es empfiehlt sich 1 Minute Vorlaufzeit einzubauen bis 
das System vollständig geladen ist. 

Das Softwareprodukt ist aktiv, es findet aber keine Nutzerinteraktion statt. 

Sind alle Werte aufgenommen, wird der Mittelwert (Leerlaufauslastung) anhand der Formel 


I 

LA: = m: jD x | 
k=1 gebildet. 

Dabei ist x_k das arithmetische Mittel des k-ten Messdurchlaufs in % (CPU-Auslastung), MByte 
(RAM-Belegung und Festplattenauslastung) oder MBit/s (Netzwerk). 
Anschließend wird die Netto-Leerlauf-Auslastung, der Leerlauf-Allokationsfaktor und die 
Effektive Leerlauf-Auslastung berechnet. Dazu kann die zur Verfügung gestellte 
Tabellenkalkulation zur Kriterienerfassung verwendet werden. 


4 Hinweise zur Erfassung der Hardware-Inanspruchnahme und Energiebedarf bei 
Ausführung eines Standardnutzungsszenarios (Kriterium 3.1.1.3) 


4.1 Messkonzept: Hardware-Inanspruchnahme und Energiebedarf bei Ausführung 
eines Standardnutzungsszenarios 


Es werden alle zum Betrieb des Softwareprodukts benötigten Softwareprodukte installiert 
(z.B. Laufzeitumgebungen, Datenbanken etc.). Anschließend wird das eigentliche 
Softwareprodukt installiert. 


Danach wird das Standardnutzungsszenario (vgl. Anhang D) automatisch abgespielt und 
währenddessen die Messung der Hardwareauslastung des SUT durchgeführt. Die Messungen 
müssen mit mindestens 10 Durchläufen wiederholt werden, 30 Messdurchläufe werden 
empfohlen (vgl. Anhang A, Abschnitt 3), ein Durchlauf des Standardnutzungsszenarios muss 
mindestens 5 Minuten dauern (vgl. Anhang D, Abschnitt 2), erfasst wird 1 Messwert pro 
Sekunde, es empfiehlt sich 1 Minute Vorlaufzeit einzubauen bis das System vollständig geladen 
ist. 
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Sind alle Werte aufgenommen, wird der Mittelwert (Brutto-Auslastung) anhand der Formel 


| n 
BAr = — Xg 


gebildet. Dabei ist x_k das arithmetische Mittel des k-ten Messdurchlaufs in % (CPU- 
Auslastung), MByte (RAM-Belegung und Festplattenauslastung) oder MBit/s (Netzwerk). 
Anschließend wird die Netto-Auslastung, der Allokationsfaktor, die Effektive Auslastung und die 
Hardware-Inanspruchnahme als Integral der Hardware-Auslastung über die Ausführungsdauer 
des Szenarios berechnet. Die Einheiten der Inanspruchnahme sind Einheiten für die 
Arbeitsleistung (also %*s, MB*s*s=MB, MBit/s*s=MBit). Zur Berechnung kann die zur 
Verfügung gestellte Tabellenkalkulation zur Kriterienerfassung verwendet werden. 


Dem Nachweis sind Angaben zum System, auf dem gemessen wurde, Angaben zum 
Standardnutzungsszenario (Welche Funktionen der Software wurden ausgeführt?) sowie 
Informationen zur Konfiguration des Softwareproduktes und des Softwarestacks - sofern diese 
vom Auslieferzustand abweichen - beizufügen. Dabei ist eines der in Anhang D genannten 
Referenzsysteme zu nutzen. 


4.2 Vorgehen zur Erfassung des Energiebedarfs 


Der Ablauf der Installation des zu messenden Softwareproduktes erfolgt die Erfassung des 
Energiebedarfs analog zum Nachweis der Hardware-Inanspruchnahme (vgl. Abschnitt 2.1 des 
Anhang B). 

Anschließend wird die Messung des Energieverbrauchs des SUT gestartet, während das 
Standardnutzungsszenario automatisiert abgespielt wird. 


Nach Abschluss der Messung, wird der Mittelwert des Energieverbrauchs anhand der Formel 
m 


| n 
in 300m 2 2 Ri 


berechnet und als Summe der pro Sekunde gemittelten Leistungsaufnahme P_i des SUT 
festgehalten. Durch die Division durch 3600 s/h ergibt sich die elektrische Arbeit in Wh. Soll 
die Messung abweichend nicht pro Sekunde aggregiert aufgenommen werden, so ist mit 
geeigneten Mitteln das Integral über die Messdauer t zu bilden und die elektrische Arbeit in Wh 
zu berechnen. 
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Anhang C Datenformat zur Weitergabe der Produktinformationen bzgl. 
Ressourcen- und Energieeffizienz 


<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" 
xmins: xs="http: //www.w3.o0rg/2001/XMLSchema"> 
<xs:element name="blauer-engel-sw-kriterien"> 
<xs: complexType> 
<xs:sequence> 
<xs: element name="Produkt"> 
<xs:complexType> 
<xs:sequence> 
<xs: element type="xs:string" name="ProduktBezeichnung"/> 
<xs: element type="xs:string" name="ProduktVersion"/> 
<xs: element type="xs: string" name="ProduktHersteller"/> 
<xs: element type="xs: string" name="SoftwareArchitektur"/> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
<xs: element name="MessungPersonelleAngaben"> 
<xs:complexType> 
<xs:sequence> 
<xs: element type="xs: string" name="MessungDatum"/> 
<xs: element name="Messender"> 
<xs:complexType> 
<xs:sequence> 
<xs: element type="xs:string" name="MessenderName"/> 
<xs: element type="xs:string" name="MessenderMail"/> 
<xs: element type="xs: string" name="MessenderSonst"/> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
<xs: element name="Messenderl nstitut"> 
<xs:complexType> 
<xs:sequence> 
<xs: element type="xs: string" name="InstitutBezeichnung"/> 
<xs: element type="xs: string" name="InstitutAdresse"/> 
<xs: element type="xs: string" name="InstitutWebsite"/> 
<xs: element type="xs: string" name="InstitutSonst"/> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
<xs: element type="xs: string" name="MessungBemerkung"/> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
<xs: element name="MessungTechnischeAngaben"> 
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<xs: complexType> 
<xs:sequence> 
<xs:element type="xs: string" name="Messgeraet"/> 
<xs:element type="xs: string" name="Abtastfrequenz"/> 
<xs:element type="xs: string" name="SzenarioLaenge"/> 
<xs:element type="xs: string" name="Stichprobenumfang"/> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
<xs: element name="MessSUTDetails"> 
<xs: complexType> 
<xs:sequence> 
<xs:element type="xs: string" name="MessReferenzsystem] ahr"/> 
<xs: element type="xs:string" name="MessSUTSystem"/> 
<xs: element type="xs:string" name="MessSUTModell"/> 
<xs: element type="xs: string" name="MessSUTProzessor"/> 
<xs: element type="xs: string" name="MessSUTCores"/> 
<xs: element type="xs:string" name="MessSUTTaktfrequenz"/> 
<xs: element type="xs: string" name="MessSUTRAM"/> 
<xs: element type="xs: string" name="MessSUTFestplatte"/> 
<xs: element type="xs: string" name="MessSUTGrafikkarte"/> 
<xs:element type="xs: string" name="MessSUTNetzwerk"/> 
<xs: element type="xs: string" name="MessSUTCache"/> 
<xs:element type="xs: string" name="MessSUTMainboard"/> 
<xs: element type="xs:string" name="MessSUTBetriebssystem"/> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
<xs: element name="AbwaertskompSUTDetails"> 
<xs: complexType> 
<xs:sequence> 
<xs:element type="xs: string" name="AbwReferenzsystem] ahr"/> 
<xs: element type="xs: string" name="AbwSUTSystem"/> 
<xs: element type="xs:string" name="AbwSUTModell"/> 
<xs: element type="xs: string" name="AbwSUTProzessor"/> 
<xs:element type="xs: string" name="AbwSUTCores"/> 
<xs:element type="xs: string" name="AbwSUTTaktfrequenz"/> 
<xs:element type="xs: string" name="AbwSUTRAM"/> 
<xs:element type="xs: string" name="AbwSUTFestplatte"/> 
<xs: element type="xs: string" name="AbwSUTGrafikkarte"/> 
<xs: element type="xs: string" name="AbwSUTNetzwerk"/> 
<xs: element type="xs: string" name="AbwSUTCache"/> 
<xs: element type="xs:string" name="AbwSUTMainboard"/> 
<xs:element type="xs: string" name="AbwSUTBetriebssystem"/> 
</xs: sequence> 
</xs: complexType> 
</xs: element> 
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<xs: element name="Softwarestack"> 
<xs: complexType> 
<xs:sequence> 
<xs: element type="xs: string" name="SoftwarestackAngaben"/> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
<xs: element name="Ressourceneffizienz"> 
<xs: complexType> 
<xs:sequence> 
<xs: element name="Hardwareeffizienz"> 
<xs: complexType> 
<xs:sequence> 
<xs: element name="MinimaleSystemvoraussetzungen"> 
<xs: complexType> 
<xs:sequence> 
<xs: element name="Indikator" maxOccurs="unbounded" minOccurs="0"> 
<xs: complexType> 
<xs:sequence> 
<xs:element type="xs: string" name="Indikator|D"/> 
<xs: element type="xs:string" name="IndikatorBezeichnung"/> 
<xs: element type="xs: string" name="IndikatorHinweis"/> 
<xs: element type="xs: string" name="IndikatorErgebnis"/> 
<xs: element type="xs: string" name="IndikatorEinheit"/> 
<xs: element type="xs: string" name="IndikatorBemerkung"/> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
<xs: element name="HWAuslastungLeerlauf"> 
<xs: complexType> 
<xs:sequence> 
<xs:element name="Indikator" maxOccurs="unbounded" minOccurs="0"> 
<xs: complexType> 
<xs:sequence> 
<xs: element type="xs: string" name="Indikator| D"/> 
<xs: element type="xs: string" name="IndikatorBezeichnung"/> 
<xs: element type="xs: string" name="IndikatorHinweis"/> 
<xs: element type="xs: string" name="IndikatorErgebnis"/> 
<xs: element type="xs: string" name="IndikatorEinheit"/> 
<xs: element type="xs: string" name="IndikatorBemerkung"/> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
</xs: sequence> 
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</xs: complexType> 
</xs:element> 
<xs: element name="HWInanspruchnahmeeEnergieBedarf"> 
<xs: complexType> 
<xs:sequence> 
<xs: element name="Indikator" maxOccurs="unbounded" minOccurs="0"> 
<xs: complexType> 
<xs:sequence> 
<xs: element type="xs: string" name="Indikator| D"/> 
<xs: element type="xs: string" name="IndikatorBezeichnung"/> 
<xs: element type="xs: string" name="IndikatorHinweis"/> 
<xs: element type="xs: string" name="IndikatorErgebnis"/> 
<xs: element type="xs: string" name="IndikatorEinheit"/> 
<xs: element type="xs: string" name="IndikatorBemerkung"/> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
<xs: element name="HWNutzungsdauer"> 
<xs: complexType> 
<xs:sequence> 
<xs: element name="Abwaertskompatibilitaet"> 
<xs: complexType> 
<xs:sequence> 
<xs: element name="Abwaertskomp] ahreszahl"> 
<xs: complexType> 
<xs:sequence> 
<xs: element name="Indikator" maxOccurs="unbounded" minOccurs="0"> 
<xs: complexType> 
<xs:sequence> 
<xs: element type="xs: string" name="Indikator| D"/> 
<xs: element type="xs:string" name="IndikatorBezeichnung"/> 
<xs: element type="xs: string" name="IndikatorHinweis"/> 
<xs: element type="xs: string" name="IndikatorErgebnis"/> 
<xs: element type="xs: string" name="IndikatorEinheit"/> 
<xs: element type="xs: string" name="IndikatorBemerkung"/> 
</xs: sequence> 
</xs: complexType> 
</xs:element> 
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</xs:sequence> 
</xs: complexType> 
</xs: element> 
</xs:sequence> 
</xs: complexType> 
</xs:element> 
</xs:sequence> 
</xs: complexType> 
</xs:element> 
</xs:sequence> 
</xs: complexType> 
</xs:element> 
</xs:schema> 
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Anhang D Referenzsystem und Standardnutzungsszenario 


[Auszüge aus: Abschlussbericht zum Projekt „Entwicklung und Anwendung von 
Bewertungsgrundlagen für ressourceneffiziente Software unter Berücksichtigung 
bestehender Methodik (UFOPLAN-SSD-2015)"] 


1 Referenzsystem 


Zum Nachweis der Ressourcen- und Energieeffizienz (Kriterien 3.1.1.2 und 3.1.1.3) muss 
der Antragsteller eines der nachfolgend genannten Referenzsysteme verwenden. Die 
Durchführung der entsprechenden Messungen (vgl. Anhang A) bei Antragstellung und 
während der Vertragslaufzeit (z.B. bei Änderung des Produktes, vgl. Kriterium 3.2.1) 
erfolgt auf dem gewählten Referenzsystem. Das verwendete Referenzsystem muss in der 
Tabellenkalkulationsdatei zur Kriterienerfassung als "Messsystem" dokumentiert werden. 
Darüber hinaus dient die Tabelle der Referenzsysteme für die Bestimmung der 
Abwärtskompatibilität (Kriterium 3.1.2.1), d.h. der Benennung des Kalenderjahrs eines 
Referenzsystems, auf dem das Softwareprodukt noch lauffähig ist. Sofern ältere 
Computersysteme (2010 - 2014) referenziert werden sollen, so muss auf die 
Computersysteme in den Tabellen 16 und 17 im Abschlussbericht zum Projekt 
"Entwicklung und Anwendung von Bewertungsgrundlagen für ressourceneffiziente 
Software unter Berücksichtigung bestehender Methodik" (UFOPLAN-SSD-2015) Bezug 
genommen werden. Das verwendete Referenzsystem zur Erklärung der 
Abwärtskompatibilität muss in der Tabellenkalkulationsdatei zur Kriterienerfassung als 
"Abwärtskompatibilitätssystem" dokumentiert werden. Messsystem und 
Abwärtskompatibilitätssystem können identisch sein. 


11 Beschreibung des Referenzsystems 


Bei den Computern des Referenzsystems "Arbeitsplatzcomputer für Büro-Software" 
handelt es sich um professionelle Desktop-Computer überwiegend in Mini-Tower- 
Gehäusen. Da die Geräte unter dem Gesichtspunkt der Energieeffizienz ausgewählt 
wurden, sind die Wirkungsgrade der eingesetzten Netzteile sehr hoch und die 
Energieverbräuche der Rechner vergleichsweise niedrig. 


Beschreibung des Referenzsystems für Windows/ Linux als Zeitreihe 2015 - 






































2019 

Technische 2015 2016 2017 2018 2019 
Parameter 
Hersteller Fujitsu Fujitsu Fujitsu Fujitsu Fujitsu 
Modell Esprimo Esprimo Esprimo Esprimo Esprimo 

P920" P9567? P957” P957'* P9581 
Prozessor Intel i5-4590 | Intel i5-6500 | Intel i5-6500 | Intel i5-7500 | Intel i5-8500 
Cores 4 4 4 4 6 
Taktfrequenz | 3,3 GHz 3,2 GHZ 3,2 GHZ 3,4 GHZ 3,0 GHZ 





11 Datenblatt: https: //sp.ts.fujitsu.com/dmspj/ Publications/public/ds-ESPRIMO-P920-OWatt-de.pdf 
12 Datenblatt: https: //sp.ts.fujitsu.com/dmsp/Publications/public/ds-ESPRIMO-P956-E90-de.pdf 
13 Datenblatt: https: //sp.ts.fujitsu.com/dmspj/ Publications/public/ds-ESPRIMO-P957-E90-de.pdf 
14 Datenblatt: https: //sp.ts.fujitsu.com/dmspj/Publications/public/ds-ESPRIMO-P957-E85-de.pdf 
15 Datenblatt: https://sp.ts.fujitsu.com/dmspj/ Publications/public/ds-ESPRIMO-P958.pdf 
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RAM 4 GB 4 GB 8 GB 16 GB 16 GB 
(DDR3, (DDR4, (DDR4, (DDR4, (DDR4, 
1600 MHz) 2133 MHz) 2133 MHz) 2400 MHz) 2666 MHz) 
Festplatte HDD SATA IlI | HDD SATA III | SSD SATA III | SSD M2 SATA | SSD M2 SATA 
(HDD / SSD) | 500 GB 500 GB 128 GB 256 GB 512 GB 
(6 Gbit/s) (6 Gbit/s) (6 Gbit/s) (6 Gbit/s) (6 Gbit/s) 
Grafikkarte Intel HD Intel HD Intel HD Intel HD Intel UHD 
Graphics 4600 | Graphics 530 | Graphics 530 | Graphics 630 | Graphics 630 
Netzwerk LAN LAN LAN LAN LAN 
GigaBit GigaBit GigaBit GigaBit GigaBit 
1.1.1 Beschreibung des Referenzsystems für Mac OS 2015 und 2019 
Technische 2015 2019 
Parameter 
Hersteller Apple Apple 
Modell Mac mini "Core |5" 2.6 | Mac mini "Core j5" 3.0 
(Late 2014)! (Late 2018) "7 
Prozessor Intel i5-4278U Intel i5-8500B 
Cores 2 6 
Taktfrequenz 2,6 GHz 3,0 GHz 
RAM 8 GB 8 GB 
(LPDDR3 SDRAM, 1600 MHz) (PC4-21300 DDR4, 2666 MHz) 
Festplatte 1 TB HDD 256 GB SSD 
(HDD / SSD) 
Grafikkarte Intel Iris 5100 Intel UHD Graphics 630 
Netzwerk LAN GigaßBit LAN Gigaßit 














16 https://everymac.com/systems/apple/mac_mini/specs/mac-mini-core-i5-2.6-late-2014- 


specs.html 


17 https://everymac.com/systems/apple/mac_mini/specs/mac-mini-core-i5-3.0-late-2018- 


specs.html 
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2 Beispiele für Standardnutzungsszenarien 


Wesentliche Grundlage für einige Indikatoren ist ein Standardnutzungsszenario, welches 
für jede zu untersuchende Softwareproduktgruppe zunächst festgelegt werden muss. 
Dieses simuliert die realitätsnahe Nutzung der Software. Das Standardnutzungsszenario 
beinhaltet die Abarbeitung von Aufgaben, für die die Software entwickelt wurde und ggf. 
die Interaktion mit dem Nutzer der Software. 


2.1 Vorgehen zur Entwicklung eines Standardnutzungsszenarios 


1. Standardnutzungsszenario entwickeln, das die typischen Funktionen des 
Softwareproduktes abbildet. Dabei ist die Häufigkeit der Nutzung dieser Funktionen zu 
berücksichtigen. 

2. Standardnutzungsszenario in der Tabellenkalkulationsdatei zur Kriterienerfassung 
(Anlage 2) beschreiben. 


Für das Standardnutzungsszenario ist eine beliebige Ausführungsdauer möglich. Ein 
Durchlauf des Szenarios muss jedoch mindestens 5 Minuten dauern. 


2.2 Überblick der Standardnutzungsszenarien für ausgewählte 
Softwareprodukte 


Der folgende Überblick gibt Beispiele für Standardnutzungsszenarien in vereinfachter 
Form: 





Textverarbeitung Mediaplayer 

Gesamten Text bearbeiten Video starten 

Inhaltsverzeichnis einfügen & aktualisieren Video vor- und zurückspulen 
Ansicht anpassen Video pausieren 

Inhalte hinzufügen & bearbeiten Wiedergabegeschwindigkeit ändern 
PDF erzeugen Video fortsetzen 

Speichern Programm schließen 











Weitere Beispiele für Standardnutzungsszenarien liegen den Vergabeunterlagen bei. 
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Das Standardnutzungsszenario "Textverarbeitung" wird im Folgenden ausführlich 
beschrieben. Diese stimmt mit der Beschreibung in der Tabellenkalkulationsdatei zur 
Kriterienerfassung überein: 


Software: Produktname 
Produktgruppe: XX 

Stand: Datum 
Bezeichnung: XX 

Autoren: Name(n) 
Referenzsystem: Jahreszahl 
Lastgenerator: Bezeichnung 


Generelle Vorgaben: 
Vor Beginn der Messung liegen 60 Sekunden Wartezeit. 


Voraussetzungen: 

Von automatisiertem Ablauf erstellte Dateien existieren nicht 
Dokument-Zoom im Programm auf 125% 

Lineale sind eingeschaltet 

Steuerzeichen sind eingeschaltet 

Einzufügenden Text in Zwischenablage kopiert 

Schriftart „XX“ installiert 


Ablauf: 





Nr. |Zeit |Tätigkeitsbeschreibung Aktionsname 





1 0:00 |Dokumentverknüpfung auf dem Desktop öffnen (Doppelklick) | start 





2 0:02 Warten bis Dokument geöffnet ist 





3 0:08 |Gesamten Text ändern textAendern 





3.1 10:08 |In den Text klicken 





3.2 ‚0:09 [Alles markieren: Strg+a 





3.3 10:11 [Schriftart ändern in „XX“ 





3.4 10:17 |Ausrichtung nach Blocksatz ändern 





3.5 ‚0:19 [Schriftgröße auf 9 setzen 





3.6 10:26 |In Text klicken, um Auswahl aufzuheben 





4 0:28 |Als neues Dokument speichern speichern 





5 0:35 |Inhaltsverzeichnis einfügen verzeichnisEinfuegen 




















Nach Ende der Messung: 
Die beiden erzeugten Dateien löschen, um die Konsistenz des Ablaufs sicherzustellen. 
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